The present invention relates to a virtual memory manager (VMM) and, more specifically, to a VMM thread interrupt offload (VTIOL) re-prioritization (VTIOLR) and infrastructure for support executions of VTIOLR processing.
In computing systems before the advent of VTIOL processing, the VMM would handle all of the received input/output (I/O) operations, such as pending read and write process requests coming in from various processes running on physical computing resources for each instance of an operating system, at the interrupt level. The VMM was thus generally configured, at least in part, as an I/O completion interrupt handler. This meant however that anytime an I/O operation would come in, the incoming I/O operation would block other I/O operations until the incoming I/O operation was finished executing. This situation, in turn, led to the provision of a cycle of blocking and unblocking by the I/O completion handler of the VMM and would continue until every incoming I/O operation was finished. Often, overall system performance was negatively affected especially in the case of delays in the ability of the VMM to handle high priority work.
VTIOL processing improved system performance by allowing the VMM to offload processing of the incoming I/O operations in cases where it made sense to do so. Therefore, a VMM with VTIOL capability would have been configured to employ several heuristics in determining whether to offload a given incoming I/O operation or not. For example, if a process is running on a given computing system that reads some data from memory and that data is immediately used it typically doesn't make sense to offload the read since the process will be blocked waiting for the data to be read anyway and offloading the request comes with some inherent overhead associated with the time taken to send requests to VTIOL processing as compared to processing those requests via the interrupt handler. On the other hand, if a process reads some data from memory but doesn't immediately use it, it can make sense for the VMM to offload that read so as to continue executing other instructions. Then, by the time the VMM gets to the instruction where that read is needed, the VTIOL will have already handled that I/O operation.